Today, there is constant demand for data entry, particularly with the use of form fields, such as a designated box on a user interface (UI), that expect a particular type of data, often formatted a particular way. In scenarios in which the form field expects a complex data type and/or format that is a composite of multiple individual data elements, the data entered into the form field is often input according to a predefined scheme that satisfies certain data parameters such as database storage or access requirements. As such, a number of difficulties can arise.
For instance, form fields that require a complex data format can be unfamiliar to novice users, even if experienced users are familiar and have little trouble entering the correct data elements in the correct format. Accordingly, when presented with a form field that expects a complex data format, the novice user will often be unable to correctly enter the expected data without time-consuming delays from failed attempts or from consulting information sources such as written manuals or advice from expert users.
For example, consider shipping software for an ecommerce business that expects address information of the purchaser to be input in a particular format, such as name/street address/optional apartment code/city/zip code/state, where each individual data element is delimited by “/”. As other examples, consider phone number formats by country or a connection string for an application to connect to a data source (e.g., web server), the correctly formatted input of which can be similar to the following: “Data Source=myServerAddress;Initial Catalog=myDataBase;User Id=myUsername;Password=myPassword;”. In the case of the shipping software scenario, it can be readily observed that experienced users might recall how to enter data into the shipping software form field, with or without an apartment code, and even for overseas addresses or for addresses that are atypical such as military bases or the like. Likewise, in the connection string example, an experienced user might recall the exact individual elements and order and be able to type that in quickly, or cut and paste the correct information from another record. On the other hand, the novice user can struggle in both scenarios.
Conventional solutions address this difficulty in one of two ways and are inadequate. For instance, an example will be shown somewhere on the UI for entering data into the form field. However, in many scenarios, the proper format for entering data depends upon a variety of factors. Therefore, examples can be of little or no value to the novice user or even harmful if the examples lead the user astray. For example, consider a Web Service endpoint or Representation State Transfer (REST)ful Uniform Resource Locators (URLs). In this scenario, URLs are formatted differently depending upon the fundamental protocol a user chooses. Hence, the URL can in one case be, e.g., “http://foo.com/bar.axd” while in another case the URL can be “https://foo:8748/bar.axd”. In other cases the URL might be directed to file transfer protocol (FTP), and therefore begin with “ftp://” or “ftps://” rather than HTML delimiters. Hence, example intended to aid the user can lead ultimately lead to more confusion.
On the other hand, other solutions break the complex data type into its individual components and provide an entry field for each of these components. Thus, instead of having a single form field, the UI will display several entry fields, e.g., one for each “Name”, “Street address”, “Apt.”, “City”, “State”, and “Zip code”. This solution does generally help the novice user input the data, given that user does not have to remember the correct order of the elements or the proper formatting such as the expected delimiters and so forth.
However, this second solution introduces several difficulties for the experienced user. Foremost, the experienced user can no longer enter data as efficiently since he or she makes added keystrokes or gestures to switch between form fields, and has lost the ability to cut and paste the entire string. Secondly, the UI is now more complex or cluttered with additional items that are not desired by the experienced user, which can lead to additional inefficiencies such as navigation of additional screens and so forth. Furthermore, in cases where the entered data depends on various factors, this approach suffers from the same shortcomings as the first solution (e.g., displaying an example) in that the actual constituent fields can vary, thereby requiring many combinations of examples or constituent fields. For another example, the input might be more compact in its complex format or string representation and thus easier for an expert to type directly. Ultimately, going from field to field may be more tedious to the experienced user.
The above-described deficiencies of today's techniques are merely intended to provide an overview of some of the problems of conventional systems, and are not intended to be exhaustive. Other problems with conventional systems and corresponding benefits of the various non-limiting embodiments described herein may become further apparent upon review of the following description.